Adaptability - a key skill for a business analyst

Alex P — Tue, 17 Mar 2009 07:39:00 GMT

I have been pondering recently on the importance of adaptability for a business analyst.

Definition of adaptability

It seems to me that adaptability is a key skill of a business analyst because no two projects are alike. It’s not possible to apply a template approach to every project situation with which you are confronted.

However, I looked up synonyms for adaptability and came across these - malleable, pliable, adjustable, compliant, easygoing. You need to be adaptable but these are sending out the wrong message - although it is important to be adaptable, equally you cannot be a pushover! The business analyst must have a set of principles that they work with and these should not be contravened.

Example

In a recent engagement, an existing project was in flight but hadn’t accommodated the requirements of another business unit as they had been unable to supply resources at the time requirements were being gathered. It was also understood that many of their requirements would match the existing set as the project was driven by new regulations that introduced new processes which all would have to follow.

I was invited to gather their requirements but time was of the essence as the existing project had progressed and was completing high level design. Any delay could risk the main project and there was a fixed deadline when the new regulations had to be met.

I recognised that we had to attempt to dive to the detail during requirements gathering in order to rapidly identify the ‘hot areas’ where the differences existed or were most likely to exist. We agreed an approach that would start with the new business process walk through without an analysis of the project goals and/or identification of the critical success factors. Once the hot areas were established, we would drill down into the detail and identify detailed requirements in these areas. This was the adaptable bit.

One principle I operate is to ensure that the early stages of the project are conducive to successful business acceptance testing. This means that all the requirements must be complete, clear, unambiguous and measurable (for more on this, see Requirements engineering and quality). In order to achieve this, the critical successs factors, business objectives and all of the existing requirements would need to be revisited after this accelerated approach. It would have to be analysed and documented whether and how they would apply for this new business unit.

Dogma

I have mentioned before (and will again) that I don’t like dogma. Anything that encourages you to follow an approach blindly feels, instinctively, that it has to be wrong. However, there is a paradox as I have certain rules that I see as inviolable which must always be observed.

The difference is that these are principles which don’t dictate how you go about something but it is important to be aware of them at all times. At any time in a project, you can refer to these principles, consider if you have adhered to them and measure your success on the project against these.

These are just my views - as ever, I would welcome any other points of view.

Alex Papworth, (this was taken from www.businessanalystmentor.com)

John Zachman at UK IIBA Meeting in February

Alex P — Thu, 05 Mar 2009 13:51:00 GMT

John Zachman provided an extremely entertaining introduction to the Zachman framework followed by an update on forthcoming IIBA activities from Martyn Wilson, chairman of the IIBA.

John Zachman

Many of you will have heard of John Zachman as his framework has been around for thirty five years or so. It is used for that much discussed, little understood art/science of enterprise architecture (could be just speaking for myself here ;-)).

John provided us with a funny, engaging and compelling presentation which was peppered with amusing anecdotes and asides. As well as being entertaining, it was a very good introduction to enterprise architecture and, more importantly, the business case for enterprise architecture.

His starting slide (and we’re talking old school projector acetates – John betrayed his academic grounding here!) explained Enterprise Physics.

To sum up, he explained how enterprises are no different to anything else in the universe, they are subject to the laws of physics and, if ignored, you will feel pain. He described enterprise architecture as a long term, not a short term endeavour and our current problem (or pain) is chronic, not acute.

He went on to explain how enterprise architecture is perceived as an information technology issue for a couple of reasons:

i) The problem is raised by the IT department

ii) The skills to solve it exist in IT

In passing, John explained how the end objective of enterprise architecture is the manufacture of an enterprise, NOT an IT system. Also, he quoted Fred Brookes in the Mythical Man Month who explained how programming is manufacturing, NOT engineering.

John showed us a slide of the colliseum and explained how many people mistakenly perceive this as architecture. The architecture was completed some time before the first stone was dragged on to the site. The building is simply one instance of that architecture. In theory, many more could have been created.

Why do we need architecture?

John explained that we don’t need architecture when:

- The object is unlikely to change

- We can perceive it in its entirety at one time

- It is simple

He explained why enterprise architecture is often perceived as an IT issue:

- The problem is raised by the IT department

- The skills to resolve it exist in the IT department

Alternatives to enterprise architecture

John explained three alternatives if we don’t have an enterprise architecture when embarking on a significant change within an organisation using the analogy of extending our room to seat 1500 from its current capacity of 100:

i) Change it anyway and take a risk. Make sure you don’t knock down any supporting walls!

ii) Reverse engineer the architecture. This will be a challenge – it might not be possible

iii) Knock it down and start again. Sounds drastic and expensive

John discussed how the Information Age is emerging from our current Industrial Age and how it is characterised by extreme complexity and extreme rates of change. In other words, our current challenges are only going to get worse.

Zachman framework

John explained the basis of the framework as a set of abstractions combine with a set of perspectives which form a matrix.

: Zachman framework

This can be downloaded as a PDF from John's website.

There was a great deal more to John's presentation but you will find many of these messages reflected on his website.

As a final comment, the message John delivered was that it is undoubtedly a very hard and challenging job to commit to creating and maintaining an enterprise architecture. There are no short cuts, however, it is necessary and critical for an organisation to be successful.

IIBA Update

Martyn Wilson gave an update on events and items of interest to the IIBA membership as follows:

Conference is planned for 28th to 30th September
with prices varying and big discounts available for multiple applicants or company applications. Prices before discount are £1,145 with discounts of 30% available (nothing on the website at the time of writing)

Conference objectives are -

increase awareness
deliver professional development opportunities
examine trends in the role
demonstrate how to be a high performing BA
promote and develop the community

The type of subjects to be covered are:

Introduction to business analysis
Future of business analysis
Secrets of top performing BA's
BA success stories
Creating a BA community

Finally, there are three 'directors at large' positions available. Nominations will be accepted from 16th March and will close at 30th March with an announcement at the end of April.

The next event will be presented by Steve Danby (head of business analysis at Prudential) on creating a successful business analysis community (25th March).